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1.  Introduction 


The  calendar  application  involves  a  wide  range  of  issues  in  distributed  computing,  from 
implementation  of  distributed  data  bases  to  design  of  a  user  interface  that  will  enable  the  user  to 
comprehend  the  complex  distributed  environment  in  which  he  is  working.  This  memo  summarizes 
current  status  of  design  and  implementation  of  calendars.  Sections  2  and  3  are  taken  from  a  progress 
report  of  March  1980  and  section  4  is  an  update  to  that  report  including  current  status  and  plans. 

We  began  our  design  of  calendar  systems  with  the  intention  of  focussing  on  implementation 
issues,  particularly  those  of  communication,  sharing  of  data,  and  the  use  of  forms  as  the  standard 
interface  among  modules.  To  assure  variety  in  our  implementation  experience,  we  generated 
alternative  designs  of  calendars.  Implementations  of  several  of  them  are  now  underway. 

During  later  design  phases  we  became  more  interested  in  the  functionality  of  the  calendar  and  its 
user  interface.  To  some  extent  the  use  of  forms  as  the  communication  medium  shapes  the  human 
interface  as  well  as  the  process-to-process  interface.  Also,  some  aspects  of  the  functionality,  most 
notably  the  notion  of  "tentative  meeting"  have  arisen  from  analysis  of  the  distributed 
implementation.1  Section  two  is  a  report  on  the  functionality  of  the  calendars  we  are  building.  Section 
three  is  about  the  distributed  implementation. 

2.  The  Functionality  of  the  Calendar 

There  are  two  kinds  of  calendars  that  we  have  been  designing  --  personal  calendars  and  public 
"resource  scheduling"  calendars. 

2.1.  The  Personal  Calendar 

The  personal  calendar  can  be  used  for  keeping  track  of  appointments,  meetings,  holidays,  etc. 
The  calendar  can  be  displayed  in  several  ways  showing  either  a  summary  of  the  week,  a  list  of 
appointments  on  a  day,  or  a  diagram  of  the  day  showing  blocks  of  free  and  reserved  time.  The  main 
operations  are  "appt”  to  make  an  appointment,  "cancel"  to  cancel  one,  and  various  display 
commands.  A  description  of  the  commands  will  be  typed  out  in  response  to  a  question  mark. 

One  cun  attempt  to  make  an  appointment  at  any  time.  If  there  is  a  conflict  wilh  another 


t. 


>slk>  I. import  inupiruri  thin  linn  ol  thought  wfwtn  ho  inslslotl  on  knowing  wltnt  my  citkmlm  dhl,  nnrl  atm  tod  In  Mp  ms 


Sicily  the  meaning  ol  a  cull  lot  a  mooting. 
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appointment,  the  calendar  reports  this  fact.  If  not,  the  appointment  will  be  made.  Appointments  are 
recorded  at  a  particular  time  with  a  few  keywords  to  indicate  the  purpose. 

2.2.  A  Calendar  for  a  Conference  Room 

The  Conference  Room  Calendar  is  similar  to  the  personal  calendar  in  that  time  slots  can  be 
reserved  and  cancelled.  This  program  is  meant  to  support  the  reserving  of  time  in  one  of  the 
conference  rooms  in  our  laboratory.  These  rooms  are  generally  used  for  seminars  the  scheduling  of 
which  may  involve  coordination  among  several  people  and  resources.  Since  a  seminar  generally  has 
a  host  who  is  responsible  for  the  reservation,  the  host’s  name  is  listed  in  the  calendar  display  as  the 
keyword  for  the  appointment,  in  addition,  there  is  a  form  on  file  for  each  appointment.  The  form 
contains  information  about  the  seminar  such  as  the  speaker's  name,  the  title  of  his  talk  and  whether 
there  will  be  refreshments.  These  forms  can  be  active,  in  which  case  they  may  trigger  communication 
with  other  calendars  (such  as  the  calendar  for  the  person  who  sets  up  the  coffee  pot  in  time  for 
scheduled  refreshments).2 

2.3.  Coordination  Between  Personal  Calendars 

A  personal  calendar  can  try  to  call  a  meeting.  The  desired  length  of  the  meeting,  a  set  of  possible 
times  and  a  list  of  participants  must  be  specified  in  the  request.  The  calendar  system  will  try  to  find  a 
time  at  which  the  meeting  can  be  held  and  will  then  notify  all  participants. 

For  meetings  that  are  called  very  far  in  advance  of  the  time  at  which  they  will  be  held,  the  meeting 
can  be  considered  to  be  tentatively  scheduled.  A  scheduler  will  keep  track  of  several  possible  times 
at  which  the  meeting  can  be  held.  A  second  meeting  is  considered  to  conflict  only  if  scheduling  it 
(and  therefore  removing  its  time  slot  from  the  set  of  times  tentatively  reserved  for  the  original  meeting) 
would  reduce  the  set  of  possible  times  to  less  than  one.  If  the  second  meeting  is  scheduled,  the  set  of 
available  times  for  the  first  meeting  is  simply  reduced.  Shortly  before  the  date  of  the  meeting  a  single 
time  is  chosen  for  the  meeting.  This  can  occur  either  at  a  "commit"  time  specified  in  the  call  for  the 
meeting  or  by  an  explicit  request  to  commit.  A  caller  could  specify  that  he  wants  a  meeting  the  week 
of  March  10th  and  that  it  should  be  definitely  scheduled  by  March  3rd.  Thus  the  caller  can  be  sure 

2 

Simple  single  process  versions  of  both  the  personal  calendar  and  the  512  calendar  have  been  implemented.  Tim  personal 
calendar  can  be  run  on  XX  by  copying  <greif>pcal  exe  and  <greif>  _  xfile.pcal  and  then  typing  peal  at  exec  For  the  512 
calendar,  copy  <greif >5 12.exe  and  <greif>_  xfile.512  and  type  512.  No  guarantees  are  made  about  the  performance  or 
consistency  with  the  description  in  this  paper.  The  programs  wilt  leave  some  files  named  "yourname.caM",  "51 2.cal.1n, 
and  H5 1 2. formal"  in  your  directory. 


that  the  meeting  will  appear  on  his  calendar  with  sufficient  advance  notice  for  planning.  If  the 
meeting  is  committed  to  a  single  time  too  soon,  it  is  quite  likely  that  some  participant  will  have  to 
cancel  in  order  to  meet  a  higher  priority  commitment  that  arises  later.  This  would  require 
rescheduling,  rather  than  the  simple  reduction  in  the  set  of  tentative  times. 

2.4.  Making  Requests  ••  The  User  Interface 

As  mentioned  above,  in  the  case  of  seminars  we  keep  a  file  of  forms  containing  information  which 
does  not  necessarily  appear  on  the  calendar  display.  For  uniformity  we  implement  all  interactions 
with  the  calendar  in  terms  of  forms  so  that  even  a  reservation  for  the  personal  calendar  is  considered 
to  be  accomplished  by  filling  in  a  form  -  a  "request  for  reservation"  form.  The  fields  are  date,  start 
time,  end  time  and  keywords.  A  cancellation  form  requires  only  a  date  and  start  time.  Requests  for 
displaying  parts  of  the  calendar  are  made  by  filling  in  the  date. 

The  user  need  not  know  what  information  is  required  for  a  particular  request  -  the  form  itself  will 
prompt  him  once  he  specifies  the  kind  of  request  he  wishes  to  make.3  This  is  a  kind  of  active  form  in 
which  the  filling  in  of  one  field  (the  type  of  request  field)  triggers  the  asking  of  further  questions  --  the 
form  only  asks  for  the  fields  that  contain  information  relevant  to  the  particular  request.  Changes  to 
entries  can  be  made  by  entering  edit  mode.  In  this  mode  the  system  asks  which  field  is  to  be  modified 
and  for  each  field,  displays  the  ok!  contents  of  the  field  and  accepts  a  new  entry.  There  is  currently  a 
distinction  made  between  fields  that  can  always  be  changed  (e.g.  title  of  a  talk)  and  those  which 
require  rescheduling  (e.g.,  start  lime).  To  change  the  latter  one  must  enter  "reschedule"  mode. 

As  we  extend  the  functionality  of  the  calendar  we  expect  that  sometimes  filling  in  one  form  will 
trigger  filling  in  an  auxiliary  form.  This  could  arise,  for  example,  when  calling  a  meeting  that  has  a 
room  requirement.  The  room  requirement  implies  that  the  seminar  request  form  must  be  filled  in  and 
sent  to  the  conference  room  calendar. 

Most  request  forms  are  disposed  of  as  soon  as  the  request  is  fulfilled.  This  is  not  true  of  the 
seminar  request  forms,  since  that  information  may  have  to  be  referred  to  (and  possibly  even  modified) 
later.  These  forms  are  kept  on  file  according  to  date  and  time  of  the  seminar.  It  should  also  be 
possible  to  file  incomplete  forms  that  are  not  yet  associated  with  a  definite  time.  For  example,  if  a 
request  conflicts  with  scheduled  meetings,  but  an  alternative  time  cannot  be  suggested  immediately, 

"Vhe  current  implementation  ot  peal  does  not  prompt  lor  all  fields  in  "appt"  requests. 
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the  user  might  store  the  form  and  retrieve  it  later,  avoiding  retyping  all  of  the  information  in  order  to 
resubmit  the  request.  A  user  interface  with  more  sophisticated  forms  manipulation  facilities  is  being 
designed  by  a  bachelor’s  thesis  student  [Wylen,  1980]. 

3.  Calendars  in  a  Distributed  System 

Facilities  for  coordinating  a  set  of  calendars  are  of  use  in  either  a  centralized  or  a  distributed 
system.  If  the  system  is  to  be  distributed,  its  implementation  will  certainly  differ  from  the 
implementation  of  a  centralized  version.  We  are  assuming  that  in  order  to  coordinate  with  another 
calendar  a  request  must  be  sent  to  that  calendar.  That  is,  there  is  no  central  data  base  that  contains 
information  on  all  calendars  and  that  can  be  accessed  directly  by  any  calendar.4  Thus  from  the  point 
of  view  of  anyone  who  needs  information  about  several  people  the  data  is  stored  in  a  distributed  data 
base. 


Operations  other  than  calls  for  meetings  may  depend  on  data  at  more  than  one  node.  For 
example,  when  there  are  tentative  meetings  (as  described  in  section  2.3)  then  while  a  meeting  is 
"uncommitted”  the  status  of  certain  time  slots  on  the  personal  calendars  of  the  participants  may 
depend  on  the  status  of  the  tentative  meeting.  Thus  even  if  the  personal  calendars  store  their  data 
locally  they  may  have  to  communicate  with  the  tentative  meeting  in  order  to  find  out  whether  a 
particular  time  slot  is  free.  This  can  cause  noticeable  delays  if  a  user  is  at  the  terminal  trying  to 
schedule  an  appointment  in  real  time.  It  also  raises  a  question  as  to  how  to  display  the  calendar  - 
should  all  tentative  times  for  various  meetings  be  shown  or  should  the  display  show  a  possible 
schedule  based  on  information  available  locally? 

Other  questions,  both  of  implementation  and  of  functionality,  arise: 

-  How  do  these  data  dependencies  relate  to  the  dependencies  which  arise  in  supporting 
modular  atomic  transactions  [Reed,  1979]?  Are  such  dependencies  at  the  application 
level  likely  to  occur  in  many  applications?  If  so,  how  can  we  support  their  implementation 
in  a  programming  language  for  distributed  applications? 

-  Should  the  caller  of  the  meeting  act  as  the  source  of  information  about  the  tentative 
meeting?  If  the  tentative  meetings  are  distributed  in  this  way  how  will  scheduling  be  done 
if  one  person  is  invited  to  several  meetings?  Should  a  central  scheduler  be  invoked  to 
manage  meetings?  (This  latter  approach  is  being  explored  by  a  DROP  student.) 


4TNs  does  not  preclude  storing  all  information  on  a  central  storage  device  such  as  the  Swallow  Distributed  Data  Storage 
System  (LCS,  1900]  Access  to  any  process'  data,  e.g.  a  calendar's  data,  would  stM  be  under  that  process*  control. 
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-  Should  chains  of  tentative  meetings  be  schedulable?  (E.g.,  can  I  schedule  meeting  A 
conditionally  depending  on  the  final  timing  of  meeting  B?)  This  may  save  the  time  of 
checking  with  the  tentative  meeting  about  a  particular  time  slot.  But  then  how  will  the 
system  help  me  in  backing  out  of  meetings  when  conflicts  are  later  confirmed? 

4.  Conclusion 

Most  of  the  user  interface  functions  described  above  have  been  implemented  in  a  single  user 
setting  and  some  simple  communicating  calendars  have  been  built.  Since  March  the  two  students 
mentioned  above  have  completed  parts  of  calendar  systems. 

Eli  Wylen  implemented  user  interface  routines  that  allow  the  user  to  chose  among  different  views 
of  the  calendar  --  week,  day,  list  of  appointments,  expanded  view  of  a  form  associated  with  an 
appointment.  He  has  also  provided  some  facilities  for  editing  calendars  and  forms,  integrating 
standard  text  editing  features  for  moving  the  cursor  around  within  a  field  with  additional  cursor 
movement  facilities  for  moving  around  on  either  the  form  or  the  calendar. 

Pat  O’Donnell,  a  UROP  student,  has  implemented  a  scheduler  that  can  handle  tentative  meetings. 
The  actions  of  the  participants,  including  the  caller  of  the  meeting,  are  currently  all  controlled  by  a 
single  process  used  for  testing  the  scheduler.  However,  the  scheduler  and  this  testing  process  are 
run  as  separate  jobs  on  XX  with  all  communication  through  message  passing. 

We  hope  to  bring  up  a  robust  form  of  the  calendar  for  general  use  on  XX  in  the  near  future.  The 
facilities  provided  would  likely  include  calendars  for  several  conference  rooms,  a  scheduler  for 
tentative  meetings,  and  personal  calendars  with  facilities  to  support  sharing,  e.g.  between  secretary 
and  faculty  member.  The  system  will  simply  provide  tools  lor  coordinating  the  use  of  distributed 
calendars  under  the  assumption  that  people  will  be  involved  in  end-to-end  protocols  such  as 
confirmations  retransmission  when  no  response  is  received  and  decision-making  when  options  arise 
in  scheduling. 
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